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I. Problem statement 

The use of real-time applications over the Internet is a challenging problem that the QoS epoch attempted to solve 
by proposing the DiffServ architecture. Today, the only existing service provided by the Internet is still best-effort. 
As a result, multimedia applications often perform on top of a transport layer that provides a variable sending rate. 
In an obvious manner, this variable sending rate is an issue for these applications with strong delay constraint. In a 
real-time context where retransmission can not be used to ensure reliability, video quality suffers from any packet 
losses. To illustrate this problem and motivate why we want to bring out a certain class of erasure coding scheme 
inside a multimedia congestion control protocol such as TFRC H], we propose this simple simulation scenario: we 
encode a CIF 'Foreman' sequence of 300 frames with two values of Quantization Parameter (QP). For a Group of 
Picture (GOP) size of 30 frames, QP 28 and 29 result in H.264/AVC videos of 531.13 kb/s (Peak Signal to Noise 
Ratio (PSNR) of 36.9 dB) and 441.37 kb/s (PSNR of 36.2 dBs), respectively. A video with QP of 28 generates 
16.9 % of redundancy bit rate compared to the one of 29. We drive the simulations with encoded video of QP 
29 protected by an Erasure Coding (Tetrys mechanism ifTTIO with redundancy of 12.5% and the one of 28 without 
protection. We randomly generate a loss rate of 1 %. In Fig. [T] we observe a strong quality degradation of the 
video without protection (blue line compared to purple line) while Erasure Coding recovers all losses within one 
way End-to-End delay constraint of 150 ms (red and green lines are identical). This implies that a slightly higher 
quality without protection suffers from any losses while a slightly lower quality video with protection can sustain 
up to a certain loss rate (3% in these simulations) depending on its redundancy. As a matter of fact, erasure-coding 
seems mandatory to enable a fair real-time video quality. 
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Fig. 1. Video quality variation in presence of packet losses with and without erasure coding 



II. HOW TO COPE WITH THESE LOSSES? 

Currently, there are two kinds of reliability mechanisms based respectively on retransmission and redundancy 
schemes. Automatic Repeat reQuest (ARQ) schemes recover all lost packets thanks to retransmissions. This implies 
that the recovery delay of a lost packet needs at least to wait one supplementary Round Trip Time (RTT) and this 
supplementary delay might exceed the threshold above a real-time application considers a packet outdated. 

A well-known solution to prevent this additional delay is to add redundancy packets to the data flow. This can be 
done with the use of Application Level Forward Error Correction (AL-FEC) codes. AL-FEC codes are FEC codes 
for the erasure channel where symbols (i.e. packets) are either received without any error or lost (i.e. erased) during 
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transmission. The addition of n — k repair packets to a block of k source packets allows to rebuild all of the k source 
packets if a maximum of n — k packets are lost among the n packets sent. In practice, only Maximum-Distance 
Separable codes (MDS), such as Reed-Solomon codes O, have this optimal property, whereas other families of 
codes, such as LDPC 0, need to receive a few number of extra symbols in addition to the k strict minimum. 
However, if more than (n — k) losses occur within a block, decoding becomes impossible. In order to increase 
robustness (e.g. to tolerate longer bursts of losses), the sender can choose to increase the block size (i.e. the n 
parameter) with the price of an increase of the decoding delay in case of erasure. In order to improve robustness 
while keeping a fixed delay, the sender can also choose to add more redundancy while keeping the same block size 
with the price of a decrease of the goodput (which is not necessarily affordable by the application). These trade-off 
between packet decoding delay; block length and throughput are, for instance, addressed in O. Another approach 
is proposed in [51] where the authors use non-binary convolutional-based codes. They show that the decoding delay 
can be reduced with the use of a sliding window, instead of a block of source data packets, to generate the repair 
packets. However, both mechanisms do not integrate the receivers' feedbacks and thus, cannot provide any full 
reliability service. Finally, an hybrid solution named Hybrid-ARQ which combines ARQ and AL-FEC schemes is 
often used. This is an interesting solution to improve these various trade-off (8). However, when retransmission is 
needed, the application-to-application delay still depends on the RTT which might be not acceptable with real-time 
applications. 

The novel coding scheme, named Tetrys ifTTI . that we propose to introduce inside a congestion control protocol 
totally departs from the above schemes. Unlike current reliability methods, this on-the-fly coding scheme allows to 
fill the gap between systems without retransmission and fully reliable systems by means of retransmissions. Tetrys 
needs only an average PLR to perform as its configuration does not depend of the size of the burst of losses. The 
main properties of Tetrys is (1) to be tolerant to any burst of source, repair or acknowledgement losses, as long 
as the amount of redundancy exceeds the packet loss rate (PLR), and (2) the lost packets are recovered within a 
delay that does not depend on the RTT, which is a key property for real-time applications. We believe that these 
properties make Tetrys a good reliability candidate for a congestion control protocol such as TFRC CQ. 

III. Issues for the Congestion Control 

The use of erasure codes as a reliability mechanism requires to identify the key properties of the congestion 
control that they have to be paired with. The next two sections detail the relevant properties of the current congestion 
control and then describes the potential solution. 

A. Congestion control and real-tune variable bit rate 

TCP have been long know as an unsatisfying solution for carrying real-time traffic. Indeed, in case of a packet 
loss, the following packets will be stored in the receiver's windows until the loss is recovered, thus inducing a 
significant delay in the communication. The window-based congestion control of TCP itself has an impact on the 
application. Sending a packet requires to wait for an acknowledgement which, in case of losses or slow-start, tends 
to arrive by burst hence increasing the delay at the sender side. Finally, despite the fact that TCP's AIMD reaches 
a steady-state, its saw-tooth behavior prevents the application to adapt its bit rate. Furthermore, the buffering at the 
sender side might overtake the delay constraint of the application. As a result, TCP would support real-time traffic 
with a fair-share at least twice bigger than the source bit rate |[T2"1 . For all these reasons, the support of real-time 
applications has turned towards protocols allowing out-of-order delivery and rate-based congestion control. 

TFRC ID is a congestion control mechanism designed to allow applications that use fixed packet size to compete 
fairly with TCP flows using the same packet size e.g. 1500 bytes. If some real-time applications such as VoIP find 
a satisfying solution in TFRC, the applications that produce variable bit rate and variable packet size experiences 
severe performance issues when their sending rate is controlled by TFRC. This is for instance the case of video- 
conferencing where the stringent delay constraint and network capacity prevent the use of CBR codecs. The video 
is encoded by independent group of picture (GoP) composed of one I-Frames followed by P-Frames with the size 
of resulting I-Frames being much larger the size of the P-Frames. As TFRC acts as a token bucket, the burst of 
packets induced by the I-frames has to be queued at the sender side before it can be entirely sent. The increased 
delay impairs on both the interactivity and the video quality in case of stringent delay constraint. The usual way 
to counter this drawback is to use padding and constantly transmit at the I-Frames rate. Obviously, it requires the 



3 



fair-share to be much bigger than the bit rate of the of the application and it reduces the overall network goodput. 
Another drawback of TFRC is the packet size that is assumed to be fixed and similar to the packet size of the 
concurrent TCP flows. Smaller packets (such as the one generated by P-Frames) are counted as full size packet 
and the required fair-share is much bigger than the actual rate generated by the codecs. 

Few work have been proposed enable VBR sources in TFRC. In [9i], the authors highlight the mismatch between 
the media rate and TFRC sending rate and propose to combine Faster Restart to TFRC to better support bursty 
applications. Although their study shows a certain improvement in terms of quality of experience for the user, the 
overall gain obtained is quite limited. The issue induced by the packet size is also partially tackled in TFRC-VP Q 
which proposes to send small packets while being fair with TCP flows sending MTU sized packets. 

B. Coupling congestion control, real-time application and erasure coding 

To the best of our knowledge, there is no transport protocol allowing source burstiness and variable packet size 
and hence the improved compression and interactivity allowed by modern codecs. While remaining TCP-friendly, 
the ideal solution should not to delay the sending of the data and the packet size should be arbitrary small. As 
a side effect, it would significantly ease the dimensioning of the erasure code in charge of loss recovery. We are 
aware that such a freedom in the packet timing might be hard to achieve -if not orthogonal to TCP-friendliness- 
and hence it should be bounded. Towards this end, the equation based congestion control TFMCC-VP lfT3l allows 
to trade packet size for packet rate while remaining fair with TCP. Configuring erasure code is a multi-dimensional 
problem involving packet rate, decoding delay, redundancy ratio, loss rate and collection capability. The higher 
the packet rate is, the more the correction capability or the required redundancy ratio will be. With TFRC, when 
congestion occurs, the packet rate reduction requires more redundancy to achieve the goal in terms of delay and 
loss recovery. With TFMCC-VP lfT3l . instead of adding a new unknown parameters that will impair the correction 
capability of the erasure code, the packet rate can remain the same. As emphasized in ifTTTl . on-the-fly erasure codes 
have a strong advantage compared to erasure block codes as for a given redundancy ratio, they shows the same 
performance than the best configuration among the erasure block codes. We consider that the robust configuration of 
on-the-fly codes combined with the fixed (or configurable) packet rate of TMFCC-VP allows a promising solution 
to enable congestion control for interactive real-time communication. 

In the context of video streaming with loose delay constraints, the authors of |[T0l suggest that the redundancy 
should not be part of the congestion-controlled rate. Their erasure block code configuration scheme predicts the loss 
rate and sends the minimum coding rate sent in addition to TFRC's rate. However their scheme is not appropriate for 
strong delay constraint applications. The proposal of (H is pushing further this idea and suggests that the redundancy 
packets should be marked and discarded following an AQM drop precedence policy. Despite the deployment of such 
scheme is questionable, we believe that solutions that send redundancy packets outside the congestion-controlled 
flow deserve to be investigated. 
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